CD Actual 3

home *** CD-ROM | disk | FTP | other *** search

/ CD Actual 3 / CD ACTUAL 3.iso / linux / system / slirp.rea < prev next >

Wrap

Text File | 1995-09-09 | 9.9 KB | 284 lines

NOTE: there's allready a program called slurp, so I've changed the name to slirp. But don't panic, it's still pronounced the same. NOTE: This is an ALPHA release! There WILL be bugs, so don't put your whole organisation's IP connectivity through it! (yet) :) What is SLiRP? -------------- SLiRP is a SLIP/CSLIP emulator which allows a normal user with a shell account on a UNIX system to act like a SLIP/CSLIP account (a-la TIA). Some of the features of SLiRP ----------------------------- * It's free * It comes with source * The TCP/IP code is based on 4.4BSD which is widely regarded as a very stable and complete implementation. This means it does all the things expected of TCP implementations. eg: slow start, congestion avoidance, exponential backoff, round-trip-time calculation, delayed ACKs, Nagle algorithm, incoming and outgoing IP fragments, etc. etc. The TCP/IP code was actually taken from the excellent FreeBSD 2.0 sources. Infact, I went out of my way to do as little modification to it as possible. Most things that I regarded as unnecessary (eg: the rfc1323 performance enhancments) were simply commented out, so if you want to experiment with them, you can. * Because SLiRP is basically the 4.4BSD TCP/IP code in userland, you can easily experiment with the theories of TCP, it's performance etc. without having to recompile and reboot a kernel. * SLiRP can redirect ports, so, for example, even though you don't have a real address on the Internet (as with all SLIP-emulators) people can still ftp, telnet, etc. into your home machine. * Redirection doesn't require a seperately compiled program, like term does (with tredir). It can be done with either a configuration file, or telnet while SLiRP is running. * Since nothing needs to be compiled on the client side, it works with any OS that can talk SLIP/CSLIP (though, there are programs which you can compile on the client end if you want, just to make life easier) Planned features: * PPP (I'm gonna steal FreeBSD 2.0's implementation, so it shouldn't take too long :) * Compression over a telnet session (One of the reasons I still occasionally use term) * trsh-like program, which lets you run multiple shells on the remote-host without the need to login multiple times (done) * tupload-like program, which will let you download/upload files without the need to login via ftp. A little more about SLiRP ------------------------- SLiRP was written because of frustration with term's cumbersome way of emulating a net-connection (to be fair, term was never written for that purpose, it's a tribute to Bill Reimers it's come as far as it has), and with the lack of source and arcane licensing of TIA (lack of source being the main frustration). Here's a little comparison to put SLiRP in perspective: ... Advantages of SLiRP over term: * Only needs compilation on one side of the link (the remote side) * No need to "port" (termify) software * Can be used by non-UNIX users (DOS/Win/Mac/etc.) * Is more secure * Is easier to use by multiple users (since you're using the kernel's networking code, which is already multi-user (well, should be...)) ... Advantages of term over SLiRP: * Compression (this is planned in SLiRP. Infact, I plan to "borrow" the compression code from term :) * Term has more complete emulation (see below) * Tupload (working on it) ... Advantages of SLiRP over TIA: * Its free * Comes with source * Its free * Comes with source * Its free * Comes with source I'm sure there are other advantages, but those are the main ones :) * CSLIP (can TIA do this?) (Don't know enough about TIA to list anymore...) ... Advantages of TIA over SLiRP: * Support (although, most of the TIA FAQ's could in theory apply to SLiRP as well.. especially the DOS/Win/Mac FAQ's) * TIA has been ported to more OS's (working on it) * Stability. TIA is more mature than SLiRP. (working on it) (Don't know enough about TIA to list anymore...) How to run SLiRP ---------------- First, compile SLiRP according to the instructions in the file INSTALL. Then all you need to do is run "slirp", quit your comms software (or disable it, or whatever) and run your SLIP/CSLIP software on your home machine. Which programs do not work over SLiRP? -------------------------------------- Any programs that bind() a port, then tell the other end of the connection where they should connect() to this bound port. For example: when you "get" a file during an ftp session, the ftp client bind()'s a socket, has a look at which port the socket is bound to, then tell's the ftp server the address and port of this socket (with the PORT command). The ftp server then connect()'s to this address/socket pair. Now, since your machine isn't really on the Internet, this connect() request will not arrive to your host, so it will not work. SLiRP emulates this by bind()ing it's own port on the server that *is* on the internet, and tells the ftp server about *that* address/socket pair. When the server connect()'s to it, SLiRP will then connect back to your machine. Currently, ftp (PORT) and irc (DCC SEND and DCC CHAT) are emulated, since these are the only programs I use which require this emulation. [I'm also working on "talk", but it's not finished yet] If you have a program that does not work with SLiRP, you can do one of 2 things: * Find out the format of the "command" and write the code to do a similar type of translation as is currently done by SLiRP. See the funcions tcp_emu() and tcp_tos() to see how this is done. * If you can't do the above, and you have the sources to the program, you can recompile it with XXX included in the SLiRP package (XXX actually, I havn't written this yet..) How do I redirect a port? ------------------------- Say you want to let your friend ftp to your home machine. Because your home machine isn't really on the Internet, they can't ftp into it directly. You need to redirect a port from the host machine (where SLiRP is running) to your home machine. There are 2 ways of doing this: 1) Put a line in your config file like the following: redir tcp [port to redirect] [your home IP address]:[port to redirect to] For example, if you want to redirect port 5000 to port 21 on your home machine (ftp port), and your home machine's IP is 123.123.123.123, you'd have: redir tcp 5000 123.123.123.123:21 Now, your friend can "ftp host.SLiRP.is.running.on 5000" and she'll be ftp-ing to your home machine. The second way is shown below... Controlling SLiRP using telnet ------------------------------ Redirection (and other misc. config stuff) can be done on the fly by telneting to a specific C class address. (Currently, 192.0.2.x) All you need to do is telnet to 192.0.2.0, which will give you a "command-line" where you can enter commands directly to SLiRP. Most of the config-file options are supported, the only ones that aren't are the ones which would crash SLiRP (eg: increasing the MTU on-the-fly will crash SLiRP) There are also aditional ones: stats [ mbuf | ip | udp | tcp | udpsock | tcpsock ] Show statistics on [ ... ]. close N Close the session which has FD N. kill N Kill the session which has FD N. And others. Type "help" to see them all (most). Notes ----- * Type "slirp -h" for a list of command-line options. * The C class address 192.0.2.xxx is a special address to SLiRP. 192.0.2.0 - SLiRP "command line" 192.0.2.1 - An alias for the remote-host, -e and -p programs will be run on connection to the specified port. 192.0.2.2 - An alias for the remote-host, but no -e, -p programs are executed. The difference between the last 2 are subtle, but distinct; for example, by default, when you telnet to 192.0.2.1 port 21 (telnet port) you'll automatically get a shell instead of a login prompt. But if you telnet to 192.0.2.2, you'll get the login prompt as offered by the remote-host. * To quit SLiRP you simple kill your SLIP/CSLIP software then send 5 0's (zeros) down the line, with a 1/2 second pause between each. * The code to try and "guess" how much it can write to the modem is flakey. If you see that your modem isn't being used at it's maximum capacity (eg: an ftp session to the remote-host, the modem's RECEIVE light is not shining brightly all the time), you might want to increase the baudrate by using the -b BAUDRATE command-line option. If you choose a number which is far greater than the actuall baud rate, SLiRP will write to the modem as fast as the OS allows, hence you'll get the maximum bandwidth. However, there will be a noticable increase in lag for interactive data (eg: a telnet session). (the -b BAUDRATE option has nothing to do with the actual baudrate, it's simply a guide for slirp so that interactive sessions are responsive) * SLiRP was written in an xterm which is 110x35 characters in size. I just had a look at portions of the source through an 80x25 character console. It is NOT pretty! :) Apoligies to the xterm-deficient. * You can choose any IP you wish for your home machine, except the following: - Any weird IP address which has some meaning to IP, like 255.255.255.255, 0.0.0.0, 127.0.0.1 (infact, all 127.xxx.yyy.zzz), etc., etc. * PING does NOT yet work, so don't use ping to test the link. Use telnet 192.0.2.0 instead. This should give a "SLiRP command-line ready." message. If not, then the link is not working. If you can't telnet/ftp to a hostname, then your DNS entry is wrong. How to contact the author ------------------------- If you have any suggestions, additions, patches, questions, comments, liquor you can e-mail me at danjo@blitzen.canberra.edu.au. You can ftp SLiRP updates and patches from blitzen.canberra.edu.au in /put/slirp. There's also a WWW page (under construction) at http://blitzen.canberra.edu.au/~danjo. I'll put the latest information on SLiRP on this WWW page, so please check this page before e-mailing me. (Of course, if you need SLiRP to work to be able to use Mosaic/Netscape/whatever, then you better e-mail me instead)